The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Transmission Control Protocol (TCP) is a transport layer protocol that provides a reliable connection-oriented data delivery service to upper-layer applications through the use of sequenced acknowledgment with retransmission of segments when necessary. In a typical TCP implementation, a TCP connection is established between two TCP endpoints that are established on two hosts. A TCP endpoint is maintained by the TCP module (or stack) of a host and is represented as the combination of an Internet Protocol (IP) address of the host and a TCP port number.
TCP uses a stream data transfer mechanism to deliver an unstructured stream of bytes between TCP endpoints. The bytes in the stream are numbered sequentially and are grouped into TCP segments for transmission over the TCP connection between the TCP endpoints. A TCP segment transmitted over a TCP connection includes a header portion and a payload portion, and can be identified by the sequence number of the first byte in the payload portion of the segment.
TCP sequence numbers are primarily used for flow control of data on the TCP connection. When a TCP connection is initially established, each endpoint generates a pseudo-random ISN (Initial Sequence Number). Each endpoint increments its ISN monotonically for each byte of data that the endpoint sends. The flow control mechanism also ensures reliable delivery by requiring the other endpoint to send an ACK (acknowledgment) for data received; each ACK identifies a received sequence number corresponding to successfully received data. The ACK mechanism ensures that the two TCP endpoints are constantly synchronized with respect to data transfer.
The transport service provided by TCP is used by upper-layer applications to exchange application-specific data over the TCP connection. One example of an upper-layer application that uses TCP to exchange data is Border Gateway Protocol (BGP). BGP is a peer-to-peer routing protocol the latest version of which, BGP-4, is defined in RFC1771 that was published by the Internet Engineering Task Force (IETF) in March 1995. In order to exchange routing information, two BGP hosts, or peers, first establish a TCP connection, and then negotiate a BGP session in order to exchange network routes. Another example of an upper-layer application that uses TCP to exchange data is Label Distribution Protocol (LDP). LDP is a protocol defined for the MultiProtocol Label Switching (MPLS) architecture and is described in RFC3036 published by IETF in January 2001. In a MPLS network, two Label Switching Routers (LSRs), or LDP peers, establish a bi-directional LDP session over a TCP connection in order to exchange label-mapping information that maps network layer routing information directly to data-link layer switched paths.
TCP, however, is vulnerable to data injection attacks. In a data injection attack, an attacker guesses parameter values for a valid TCP connection and uses these parameter values to send spurious TCP segments that contain malicious or spurious data payloads. These spurious TCP segments may affect the state of the TCP connection itself or may be intended for an upper-layer application. If the receiving TCP endpoint passes such segments to the upper-layer application various problems may occur when the application acts on or executes the data payloads. The consequences of data injection attacks can be severe. For example, when a BGP session is disrupted by a change in the state of the associated TCP connection, the BGP peers that established the session may have to discard all BGP routes that were exchanged during the session and may have to re-synchronize their routing information with peer routers in the network.
One type of a data injection attack is a to construct and send spurious TCP segments that request closing and re-setting of the TCP connection by setting the RST (reset) bit in the TCP segment's headers.
One prior approach for preventing such data injection attacks minimizes the chances that an attacker would be able to determine the parameters of a valid TCP connection. In this prior approach, a TCP endpoint computes a digital signature (or message digest or message authentication code) for each TCP segment that it sends, and includes the signature in the TCP segment header. The signature is computed based on a key or a password known only to both TCP endpoints, and uses the contents of one or more fields of the TCP segment as input. Thus, in order to successfully launch a data injection attack, an attacker would not only have to determine the valid TCP connection parameters, but would also have to guess the key or password used to produce the TCP segment signature.
One particular implementation of this prior approach, which is used for protecting BGP sessions, is described in RFC2385 published by IETF in August 1998. In this implementation, a TCP OPTION has been defined for carrying a Message-Digest5 (MD5) hash value in a TCP segment. The MD5 algorithm (as defined in RFC1321 published by IETF in April 1992) takes as input a message of arbitrary length and produces as output a 128-bit signature, or “message digest”, of the input. In this implementation, every TCP segment sent on a TCP connection contains, in the OPTIONS field of the TCP segment header, a 16-byte MD5 signature produced by applying the MD5 algorithm to the following items in order:                1. The TCP segment pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length);        2. The TCP segment header (excluding the OPTIONS field, and assuming a checksum of zero);        3. The TCP segment data (if any); and        4. An independently-specified key or password known to both TCP endpoints and presumably specific to the TCP connection.        
Upon receiving a TCP segment signed with a MD5 signature, the receiving TCP endpoint computes its own digest for the TCP segment from same data and by using its own key. The receiving TCP endpoint then compares the computed digest with the MD5 signature included in the OPTIONS field of the TCP segment. If the computed digest matches the MD5 signature included in the TCP segment, the receiving TCP endpoint validates the TCP segment and passes the payload portion of segment to the recipient upper-layer application. If the comparison fails, the TCP endpoint silently discards the TCP segment and sends back no acknowledgement.
The above approach, however, has numerous disadvantages. One disadvantage of the above approach is that, although difficult, it may not be impossible for an attacker to produce a valid signature for a malicious TCP segment that it wants to inject in the TCP connection. For example, since the MD5 algorithm is prone to a successful cryptanalytic attack, it is not impossible for an attacker to sniff a large number of similar TCP segments and to deduce the key used to create the MD5 signatures for TCP segments. This disadvantage causes serious security concerns, especially for upper-layer applications, such as BGP, that use TCP connections to run sessions for very long periods of time.
Another disadvantage of the above approach is that in some situations it is very difficult to change the TCP connection keys without significant disruption to upper-layer applications. Since both TCP endpoints must use the same key to produce signatures for the TCP segments associated with a TCP connection, when the key associated with a TCP connection needs to be changed, both TCP endpoints must change the key nearly simultaneously in order to prevent loss of data transmitted between the upper-layer applications over the TCP connection.
For example, in a BGP implementation that is in accord with RFC2385, when BGP peers establish a BGP session with each other over a TCP connection, both BGP peers may configure their respective TCP endpoints to use a shared MD5 key or password. The shared MD5 key may be provisioned to the BGP peers beforehand. Some situations may arise, however, which require that the MD5 key must be changed. For example, a MD5 key may need to be changed because of security concerns related to personnel changes (e.g. a network administrator leaving the company). In another example, if the BGP session is a long running session and is established between a BGP peer in an Internet Service Provider (ISP) network and a BGP peer in a customer network, it may be desirable to change the MD5 key periodically in order to prevent a potential attacker from guessing the key by sniffing and analyzing a large number of TCP segments sent over the TCP connection associated with the BGP session.
However, once the BGP session is established there is no practical way to change the MD5 key because BGP uses its own KEEPALIVE mechanism to detect whether the BGP session is active. BGP peers disable the TCP HoldTimer for the TCP connection, and use their own BGP KEEPALIVE HoldTimer, the value of which is negotiated during the establishing of the BGP session. A BGP peer would periodically send BGP KEEPALIVE messages to ensure that the HoldTimer on its BGP peer does not expire. For example, if the BGP peers negotiate the default BGP HoldTimer interval of 180 seconds, absent the exchange of any other BGP messages a BGP peer would send a BGP KEEPALIVE message every 60 seconds or so. If the BGP peer does not receive a communication over the BGP session within the BGP KEEPALIVE HoldTimer interval, it sends out a HoldTimer Expired Error and closes the BGP session.
Thus, if the MD5 key, which is used by a BGP peer in BGP session established over a TCP connection, needs to be changed, the key must be changed on both TCP endpoints within an interval of time that is smaller than the BGP HoldTimer. The interval of time during which the keys are changed on both TCP endpoints must be smaller than the BGP HoldTimer in order to prevent the TCP endpoint from silently discarding TCP segments signed with the old key that carry BGP messages of the BGP session. However, in a large network such as an ISP, it may be difficult to change the MD5 keys on all TCP endpoints that support BGP peers within an interval of time as small as a BGP HoldTimer interval.
Certain protocols such as BGP, RIP and IS-IS use timer-based synchronization to trigger key rollover for a session. However, all such existing key chaining mechanisms depend upon synchronization of the system clocks of the endpoints to accurately accomplish concurrent key rollover. If the clocks are not synchronized at both ends of a connection, password rollover may fail, resulting in a reset of the connection or session.
Another possible approach is to modify TCP to explicitly carry bits or fields that signal a change in MD5 keys. However, this approach requires specialized logic to interpret the signaling, and requires management of signaling messages at the endpoints.
Another possible approach is for a first endpoint to unilaterally change message authentication keys at any particular time, generate a message authentication tag based on the changed key, and send the message and message authentication tag to the second endpoint. If the second endpoint cannot authenticate the message based on a current key, the second endpoint changes key and tries again. If changing to a second key results in successful message authentication, then the second endpoint knows that the first endpoint has changed keys.
However, this approach is computationally expensive because a receiving endpoint must compute multiple authentication tags at each switchover. The endpoints also may have packets held in out-of-order buffers and must properly handle authentication of such packets with several keys. Further, a malicious user who injects a spoofed data segment into the network potentially can force endpoints to repeatedly compute multiple authentication tags.
The preceding approaches are illustrated, for example, in Mynam et al. I and Mynam et al. II, cited above.
Based on the foregoing, there is a clear need for techniques that overcome the disadvantages of the prior approach described above for preventing data injection attacks.